Asynchronous communication is the exchange of messages, such as among devices in a communications network, by reading and responding as their schedules permit rather than according to some clock that is synchronized for both the sender and receiver. In an asynchronous messaging environment, the communication takes place between two or more applications, devices, or systems, whereby the system places a message in a message queue and does not need to wait for a reply to continue processing, and both the sender and receiver need not be available or online at the same time, but rather, read and respond as their schedules and desires permit. Examples include email, discussion chats, and forums, and text messaging over cell phones. The message delivery and response can be in seconds, minutes, or days depending on when the receiver becomes online. This is more convenient for the sender and receiver since they are not required to be online at the same time.
In modern messaging applications for cell phones, the asynchronous communication method is often adapted to transmit textual data, upload and download multimedia for speed, and to support higher numbers of concurrent user access. Modern asynchronous messaging applications commonly employ asynchronous communication protocols such as the WebSocket protocol, a bidirectional protocol with no predefined message pattern such as request/response. The WebSocket protocol allows both the client and server to send messages without waiting for each other and therefore supports full-duplex, true asynchronous communication, increasing scalability and building a near real time interactive application. Examples of asynchronous messaging applications known in the art include the WhatsApp™ messenger, the Telegram™ messenger, the Line™ messenger, the WeChat™ messenger, the Facebook™ messenger, and the Google Hangouts™ messenger. WhatsApp™ is a trademark of WhatsApp Inc. Mountain View, Calif., United States. Telegram™ is a trademark of Telegram LLC in Wilmington, Del., United eStates. Line™ is a trademark of LINE CORPORATION, Tokyo, Japan. Google Hangout™ is developed by GOOGLE, INC. in Mountain View, Calif., United States.
Modern messaging applications also sometimes support a synchronous communication method when the messaging application offers voice calls or video calls where synchronous communication is used to transmit voice or video data. Synchronous messaging or direct communication is when communication takes place between two or more applications, devices or systems, where the system places a message in a message queue and then waits for a message response before it continues processing. The information is synchronized using a clock signal and all parties involved in the communication must be present at the same time. Telephone conversations, video conferencing, and instant messaging are examples of the use of synchronous messaging where the data transmission happens in real time and requires both sender and receiver parties to be available and online at the same time while the data transmission occurs. Some embodiments of synchronous conferencing include what is sometimes called online chatting, which is sometimes extended to include audio/video conferencing or instant messaging that provides text based messaging for multi-user online chat. Examples of synchronous conferencing protocols include Internet Relay Chat (IRC), Protocol for Synchronous Conferencing (PSYC), Secure Internet Live Conferencing protocol (SILC), Extensible Messaging Presence Protocol (XMPP), and SIP for Instant Messaging and Presence Leveraging Extensions Protocol (SIMPLE).
In typical asynchronous messaging applications, the sender user sends a message to a user or plurality of receiver users, and the message request includes the message body and the receiver user identification or plurality of users' identifications. The message is transmitted to a server computer which stores and forwards the message to the receiver users when the receiver users become available. The message could be textual data, multimedia such as image, audio, and/or video. It is common for each user to have a profile containing identity information about the user. The profile may contain a name, short description, and image known as avatar. The profile may be transmitted to the other users of the asynchronous messaging system prior or near to the message transmission. The other users may view the user profile from time to time.
Also common in asynchronous messaging systems, a user registers and creates a profile at the time of registration and the system reads all user contacts and forwards the user profile to registered user contacts. The registered user contacts receive the user profile and store it locally in a memory or storage of a user device or computer associated with the user. When the user sends a message to other users, the other users receive the message and the asynchronous messaging client displays the sender user profile which is stored on the receiver user local device or computer memory along with the content of the message. As the nature of the system is asynchronous, there is no guarantee that the user profile will be sent and available at the receiver user's device prior to the content of the message transmission, therefore a subset of the sender user profile may be transmitted along with the message until the sender user profile is completely transmitted.
It is also common in asynchronous messaging systems that a user may designate different classifications for contacts, such as personal contacts, professional contacts, and other unclassified contacts. Known asynchronous messaging systems generally enable a user to create only a single profile, however, which is ultimately sent to all contacts of the user.
In such systems, it is also common that the user may update the profile from time to time. As soon as the update is completed the asynchronous messaging client may send the updated profile to the server and the server may store and forward the updated profile to other users when they become available.
One difficulty arising from the implementations of user profiles in known asynchronous messaging systems is that the content a user may wish to include in his profile and which may be suitable for viewing by other users in some of the classifications of his contacts—for example, personal information, where the contact is classified as a friend or family member—but may not wish the content to be viewable by other users in other classifications of his contacts—for example, professional contacts such as an employer, an employee, or a customer. The user must therefore choose between compromising his privacy preference in order to include the content, or censoring his own profile.
Another difficulty resulting from profile updates relates to the use of user groups. Many asynchronous messaging systems allow the user to send a message to a plurality of users. Typically the plurality of users may be assigned or invited to join a group, whose identification is stored along with the assigned users' identifications at the server computer. When the message is transmitted to a specific group identification, the message is received by the server computer and the server computer stores and forwards the message to the group's assigned users when they are available. The widespread use of the asynchronous messaging applications makes it necessary for the system to adapt to larger group sizes (on the order of thousands of users) at which time profile updates become a challenge.
Some synchronous conferencing systems adopt or employ multiple profiles. For example, U.S. Pat. No. 8,332,761, the contents of which are incorporated herein by reference, discloses a synchronous conferencing system to manage multiple profiles where both sender and receiver parties must login to a synchronous conference server to obtain connection information and where each of the sender and receiver parties can exchange messages and profiles directly and must be online. The problem with this arrangement is that it provides no solution for asynchronous messaging systems where both sender user and receiver users are not required to be online and interact independently.
There would be value, therefore, in a solution that overcomes the above-mentioned limitations of known techniques and which provides and enables multiple user profiles in an asynchronous messaging environment.
In the drawings, features or elements are generally identified using reference characters comprising numerals (e.g. “10”). Reference characters comprising a numeral followed by one or more letters (e.g. “10A” or “10B”) are intended to designate a particular instance of a feature or element designated more broadly by the numeral alone (e.g. “10A” or “10B” designate particular instances of feature or element “10”), and thus any characteristics ascribed to such particular instances, when referenced as such, are not necessarily possessed by all instances of the more general feature or element.